NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/18182

Internet Message Format | 1996-08-05 | 5.9 KB

Path: ix.netcom.com!news
From: [e-mail](Giuliano Carlini)
Newsgroups: comp.lang.c++
Subject: Re: Why don't you use garbage collection
Date: 18 Apr 1996 21:51:20 GMT
Organization: Netcom
Message-ID: <4l6dgo$[e-mail]>
References: <[e-mail]> <1996Apr16.110526.1846@ittpub>
NNTP-Posting-Host: lbx-ca5-09.ix.netcom.com
X-NETCOM-Date: Thu Apr 18  4:51:20 PM CDT 1996

DISCLOSURE: I'm associated with geodesic systems the publisher of Great
Circle - a garbage collection library - and hope to earn royalties from
them. You can check them out at www.geodesic.com.

If you would like a non-commercial library, check out Hans Boehm's
garbage collector at ftp://parcftp.xerox.com/pub/gc.

MA> In article <[e-mail]>,
MA> [e-mail] (Matt Austern) wrote:
MA>In C++ we're used to the idea that heap-allocated and
stack-allocated
MA>objects have different rules.  It's not so radical to introduce
MA>garbage-collected objects as a third category.

WIL> In <1996Apr16.110526.1846@ittpub> [e-mail] (Wil Evers)
WIL>1. Don't we think C++ is complex enough as it is?  In my
experience, the
WIL>main obstacle to get people to use C++ is its steep learning curve,
and
WIL>adding yet a third category of objects wouldn't make things any
easier.

Adding a third class of objects to the language won't happen any time
soon. The standards committee just ain't going to do something they
consider to be "big". As others have noted, Ellis and Detlefs have
proposed such a change to C++. What isn't as well known, is that the
available collectors that I'm aware of provide an abstract base class
which simulates this proposal very closely.

Does this make things easier or harder. You decide:
    class C1 : public gc { ... }; // objects of class C1 are collected
    class C2 { ... }; // objects of class C2 are not.
You can also specify on a per allocation basis whether an object is
collected to override the above behavior:
    v = new(NOGC) C1; // allocate a C1 which is not collected
    v = new(GC) C2; // allocate a C2 which is collected.
Personally, I believe the tiny investment in learning the above is
repaid thousands of times over. Learning the above takes 2 minutes.
Finding and fixing a memory leak can take hours.

WIL>2. Will the destructors of garbage collected objects be called?

If you want to. Both Great Circle and Hans Boehm's collectors can
invoke the destructor on an object by object or class by class basis.
Or, if you prefer, an arbitrary finalization function can be called.

WIL>4. If the answer to (2) is YES: when will these destructors be
WIL> called?
When the object isn't reachable from the root set <g>. If you need to,
you can force a collection to occur at any time.

WIL>What can we assume about the state of the program when
WIL>the destructor runs?
Finalization occurs after the collector is run. It is therefore safe
to allocate memory during finalization, although I can't see why a
"real" program would have to.

WIL >How do we guarantee a shortage of non-memory resources is detected
WIL>by the garbage collector before we get to the point where the
WIL>program can't continue?
Your program runs out of memory, the collector runs and recovers
memory. If it couldn't recover any, your fried. But this is just as
true of malloc; if it can't find memory, your program dies.

In <[e-mail]> [e-mail]
(Lars Farm) writes:
>.. Anyway, this wont happen.
>GC seems not to appeal to the committee members. If it did GC would
shurely
>be in the language by now.

While it would be better if it were in the language, it isn't
essential. Libraries which conform to the Detlefs/Ellis proposal exist,
and work fine. If the committee changes there mind at some time,
whatever they do will probably conform to it too. And I bet they will
in the next go 'round. After all, Stroustrup was at first dead set
against GC, and his latest statements support the optional use of it.
Of course, it'll be a few years before anyone will even think of
changing the standard.

CLG> In <[e-mail]>
CLG> [e-mail] (Carl Laurence Gonsalves)
CLG> writes:
CLG> ...
CLG> >The "GCTransparent" way only requires that you link with a
special library.
CLG>It looks like Great Circle scans the stack, the registers, and the
static data area looking for pointers to data on the heap. Of course,
at run time
CLG>there's no way to tell what's a pointer and what's not, so it just
assumes
CLG>that every word is a pointer. <snip>
Yep.

CLG>This seems like a classic example of making a bug look like
CLG> a feature.
Huh???!!!

CLG> I may have code that hold a bunch of random integers. The chance
that some of
CLG>these random integers just happen to look like pointers to
something on the
CLG>heap is pretty high.
The Boehm and Geodesic collectors are quite sophisticated, and employ a
technique called "Blacklisting" to minimize this. But, this still can,
and does, happen. But, over time, as variables' values change, the
falsely retained blocks will be recovered by future collections.

The amount of falsely retained memory is typically bounded and small.
That is, it doesn't keep growing and growing. A memory leak does.

CLG>The other way of using Great Circle ("GCPointers") uses some form
of
CLG>garbage collecting smart pointers. I have to wonder how well this
works
CLG>with other libraries though.

I'm not much of an expert on their GCPointers library.

CLG>Even so, the GCPointers idea seems less disagreeable than the leaky
CLG>alternative. I'd really like to know how it could work with
third-party
CLG>libraries though.

GCTransparent and the Boehm collector really don't leak - that is
falsely retain - much memory at all. I'd say less than .1% as a guess.
But, if you're really concerned about it, GCPointers is available.

CLG>Would it be possible to use STL containers, for example, with
GCPointers?

I believe so. But, I could be wrong.

g